\chapter{Implementação e Testes}
O presente capítulo trata de detalhes da implementação das ferramentas de ataque e como foram realizados os testes.
São abordados os aspectos e escolhas que levaram as ferramentas à sua forma final, detalhes de como foram testados os ataques e
quais ferramentas foram usadas para os testes.

\section{Implementação}
Como prova de conceito do ataque, foram confeccionadas várias ferramentas e
para a confecção dessas ferramentas de ataque foram feitos vários protótipos e aprimoramentos até que as ferramentas escolhidas chegassem em seu 
estado final. Muitos testes foram realizados deixando claro que alguns métodos não seriam eficientes como ferramenta e por 
consequência chegando-se a um concenso de quais seriam as mais adequadas para um teste completo.
As ferramentas que serão citadas nesta seção são apenas referentes aos produtos finais, para não alongar desnecessariamente o 
seu conteúdo.

Foi escolhido como linguagem de programação, C/C++. A escolha vem da rapidez no tempo de execução e da portabilidade do código 
para vários sistemas operacionais. Além disso umas das ferramentas usa o aplicação multiplataforma e U.I. framework QT\textregistered~\cite{qt}, escolhida pelo 
enorme acervo de bibliotecas(incluindo bibliotecas para o uso de funções de rede), facilidade para o design e criação de 
interfaces gráficas. Usando QT\textregistered~\cite{qt} pode-se programar em C/C++ com um pequeno overhead para enormes vantagens
e ainda mantendo a portabilidade. A aplicação/framework inclusive possui funções para sockets já implementadas e threads, que foram usadas
para agilizar o processo de simular vários clientes em uma única máquina atacante.

Para garantir que o uso da ferramenta com QT\textregistered  não estivesse com um overhead significativo, foi feito uma outra ferramenta
similar mas usando POSIX threads~\cite{posix}, uma API seguindo o padrão POSIX que permite o uso de threads, muito popular entre os usuários
de sistemas UNIX. Em vários testes, ambas as ferramentas com POSIX threads e QT\textregistered  tiveram o mesmo desempenho, optou-se
então em manter a ferramenta usando QT\textregistered  e abandonar as POSIX threads.

Outras ferramentas acabaram por usar a API libevent~\cite{libevent} que mostrou-se bem eficiente. A API trata eventos relacionados a funções
do sistema operacional sendo bem eficiente em lidar com múltiplas instâncias\footnote{A API usa de processos de escalonamento para simular várias execuções, mas não são execuções reais, sendo diferentes de \emph{threads} ou novos processos. A multiplicidade simulada pela API será denominada por termos como clientes/instâncias.}
de eventos envolvendo chamadas ao sistema. Como as
ferramentas em si precisam de múltiplas chamadas ao sistema operacional, pois usam funções de rede quase que exclusivamente, a API
por mais complicada que fosse mostrou-se um par perfeito para as ferramentas. A sugestão de usar a API veio de comentários e 
sugestões recebidas no \emph{blog} de Vincent Bernat~\cite{vincent}, já citado anteriormente.

Para os \emph{handshakes} TLS/SSL não foi usada nenhuma biblioteca criptográfica, todos os pacotes foram confeccionados de forma semi-automatica
e \emph{byte} a \emph{byte} adequando-se as necessidades das vítimas. 

Antes de entrar no mérito do resultado final das ferramentas, é desejado relembrar que esse documento tem propósitos acadêmicos
apenas e não pretende causar mal, e sim ajudar. Tendo isso em mente, reforça-se que nenhum artefato será disponibilizado para a comunidade, eles
serão mantidos confidencialmente entre autor e orientador.

Quatro ferramentas obtiveram maior destaque e foram consideradas mais relevantes para os testes envolvendo servidores reais.
Duas das ferramentas foram criadas usando a API libevent~\cite{libevent}, a API trabalha baseada em eventos, então, sempre que um
pacote é recebido do servidor(evento) a ferramenta responde enviando o próximo pacote (próximo evento). Esse comportamento é idêntico
ao comportamento real onde as mensagens entre cliente e servidor são intercalados entre si até o final do handshake. A diferença
entre as duas ferramentas usando da API libevent está no fato de uma usar apenas \emph{ciphersuites} baseadas em RSA e a outra em
Diffie \& Hellman, escolhidas justamente para mostrar a diferença de força entre os ataques e averiguar se o \emph{perfect foward secrecy}
é realmente mais seguro ou na verdade mais perigoso (rever capítulo anterior).

As outras duas ferramentas foram implementadas usando o framework QT\textregistered e suas threads~\cite{qt}. A primeira ferramenta faz com que suas
threads esperem uma resposta do servidor para então respondê-la, assim como o protocolo descreve. A segunda versão da ferramenta
faz com que as mensagens dos \emph{handshakes} sejam mandadas o mais rápido possível, possuindo um caráter mais volumétrico. Essa
segunda versão verifica se a conexão TCP(acima da conexão SSL) está ativa, em caso afirmativo ele manda a continuação das mensagens sem
esperar que o servidor mande a resposta. Esse comportamento garante que o servidor ficará sempre ocupado pois as mensagens do 
cliente chegam uma após a outra. Caso a conexão tenha sido encerrada por qualquer motivo a conexão é restabelecida e o processo continua.
Essa segunda abordagem ganhou destaque pois mesmo que o servidor não fique com uma conexão ociosa esperando o cliente, ele recebe
mais \emph{handshakes} 'incorretos' e logo gasta maior poder computacional decifrando.

\begin{table}[H]
\caption{Descrição abreviada das diferenças entre as quatro ferramentas.}
\centering
\label{tab:tools}
\begin{tabular}{|p{3cm}|p{3cm}|p{3cm}|p{3cm}|}
\hline
\multicolumn{4}{|c|}{Tabela de Ferramentas}\\
\hline
\multicolumn{2}{|c|}{Libevent}	&\multicolumn{2}{|c|}{QT\textregistered}\\
\hline
RSA	&DHE	&Versão 1	&Versão 2\\
\hline
Usa apenas \emph{ciphersuites} que usam RSA como protocolo de acordo de chaves	&Usa \emph{ciphersuites} que usam de Diffie\&Hellman	&Essa versão sempre espera uma mensagem do servidor para responder, seguindo a lógica normal do protocolo	&Essa versão manda respostas e requisições o mais rápido possível e sempre que possível\\
\hline
\end{tabular}
\end{table}

Em resumo, 4 das ferramentas desenvolvidas se destacaram em testes simplórios e avançaram para os testes envolvendo servidores reais. Para
evitar confusões futuras as 4 ferramentas destacadas serão mencionadas da seguinte forma: primeira versão (usando QT\textregistered
e threads), segunda versão(usando QT\textregistered, threads e o comportamento impaciente), versão com libevent e RSA, versão com 
libevent e DHE(Diffie \& Hellman efêmero). Para maior facilidade, as peculiaridades das ferramentas estão resumidas na tabela ~\ref{tab:tools}
acima.

Todas as quatro ferramentas descritas, fora suas peculiaridades, têm o mesmo comportamento geral. A primeira parte desse comportamento geral
das ferramentas é testar se o endereço fornecido a elas corresponde a um servidor e se esse servidor aceita conexões seguras TLS/SSL.
Isso é feito mandando a primeira mensagem do \emph{handshake} TLS/SSL que está gravada no código do programa, caso o servidor responda e sem um alerta ele é um alvo viável
para o ataque. 

A segunda parte da rotina é verificar quais \emph{cipher suites} são aceitas pelo servidor, de preferência escolher a mais lenta. 
Dentre uma lista de prioridades de \emph{cipher suites} já testadas, a ferramenta escolhe a mais lenta suportada pelo servidor.
Essa etapa é feita mandando vários primeiros pacotes de \emph{handshake} com apenas uma \emph{cipher suite} cada, então o 
servidor responde com um alerta às quais não suporta. Essas \emph{cipher suites} foram testadas previamente\footnote{

As \emph{ciphersuites} mais onerosas foram escolhidas de acordo com o \emph{benchmark} proposto por Vincent Bernat em seu blog ~\cite{vincent}.

} e já estão no código
da ferramenta, pois uma leitura delas junto com o ataque poderia não ser fiél devido a instabilidades momentâneas e além disso
deixaria o ataque mais evidente. Mais detalhes na figura ~\ref{fig:cipherOnerosas} abaixo.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.7]{figuras/cipherOnerosas.png}}
\caption{Imagem contendo o \emph{benchmark} de \emph{ciphersuites} usado como parâmetro~\cite{vincent} (adaptada para o português).}
\label{fig:cipherOnerosas}
\end{figure}

Em seguida as ferramentas montam os pacotes que serão usados para resposta, os pacotes já estão semi-prontos no código só precisam
de detalhes simples como tamanho de chaves e etc. Os pacotes então são levemente adaptados, as \emph{timestamps} dos pacotes
são colocadas com a mesma data para agilizar o processo, o pacote com 'lixo' é montado usando valores aleatórios
e do tamanho correto(os prévios \emph{handshakes} disponibilizam esse dado).

Para finalizar e começar a negação de serviço em si, são disparadas as threads ou clientes. Cada thread ou cliente possue o mesmo comportamento,
dispara \emph{handshakes}
atrás de \emph{handshakes}, usando os pacotes já montados na etapa anterior. O processo continua até que o usuário resolva interroper
o ataque.

O comportamento geral das ferramentas está resumido na figura ~\ref{fig:fluxo} abaixo, todas as 4 ferramentas seguem o fluxograma mostrado
mas mantendo a diferenças citadas.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.4]{figuras/fluxoMono3.png}}
\caption{Imagem contendo o fluxograma de como as ferramentas funcionam. Diferenças bem sutis diferenciam as ferramentas, mas o funcinamento padrão é o esquematizado.}
\label{fig:fluxo}
\end{figure}

\section{Ferramentas e metodologia usadas nos testes}

Os principais objetos de teste são o atacante, o cliente e o servidor. O cliente é o usuário legítimo, que sofrerá a degradação de serviço ou sua completa negação,
por isso é importante mensurar o impacto sofrido, além disso monitoramento no servidor é necessário para medir a intensidade do ataque
e como o ataque se desenvolve para causar a negação de serviço.

Para medir o efeito do ataque no servidor, o mesmo terá seu gasto de CPU monitorado, junto com a quantidade de conexões ocupadas e
ociosas. Como o cliente interage com o servidor apenas para fazer requisições e receber respostas, o 
cliente será monitorado para o aumento do tempo de resposta de suas requisições. Por exemplo, um cliente requisita uma página \emph{web}
e essa página demora cerca de alguns milisegundos para ser entregue. Assim, durante o ataque será monitorado o acrécimo desse tempo de resposta.

Os testes forão todos realizados em ambiente isolado para se ter maior controle, menor interferência e evitar problemas
legais, pois ataques de negação de serviço podem ser enquadrados como crime cibernético. O ambiente de teste consiste de três máquinas,
um servidor, um atacante e o cliente. Essas três máquinas serão ligadas diretamente usando um roteador a/b/g/n e cabos, para assim
obter-se menor atraso nos pacotes, eliminar tráfego externo e executar uma melhor medição. Um ataque real, entretanto, teria um desempenho
melhor pois contaria com a presença de outros clientes ocupando o servidor, tráfego externo atrasando os pacotes do cliente, atraso nas respostas
do servidor (devido a um maior número de nós entre cliente e servidor) e maior gasto computacional do servidor devido a processos internos
(no teste, o servidor apenas responde requisições, não possuindo nenhum sistema \emph{web} implementado à parte).

\begin{figure}[H]
\centerline{\includegraphics[scale=0.6]{figuras/bancada.png}}
\caption{Imagem descrevendo a organização da bancada de testes. Atacante, cliente(simulando usuário legítimo) e servidor são todos ligados por cabos a um roteador exclusivo e isolado.}
\label{fig:bancada}
\end{figure}

Segue abaixo a descrição das máquinas usadas como servidor e atacante para mérito de comparação.

\begin{table}[H]
\caption{Configuração de hardware e software das máquinas atacante e servidor.}
\centering
\label{tab:config}
\begin{tabular}{|c|c|}
\hline
ATACANTE	&SERVIDOR\\
\hline
Notebook Samsung\textregistered	&Desktop customizado\\
\hline
Kubuntu(Ubuntu 13.10)	&Kubuntu(Ubuntu 13.10)\\
\hline
Intel\textregistered Core i7 2.2GHz	&Intel\textregistered Core i7 2.93GHz\\
\hline
8GB memória RAM	&8GB memória RAM\\
\hline
  &Apache Server 2.4.6(Ubuntu)\textregistered\\
\hline
\end{tabular}
\end{table}

Pode-se ver da tabela ~\ref{tab:config} que atacante e servidor possuem configurações bem parecidas, com o servidor possuindo um
processador um pouco melhor.

Para a análise do tráfego durante o ataque foi usada a ferramenta Wireshark\texttrademark ~\cite{wireshark} que é capaz de captar todos os pacotes de
rede em um nó e tem diversas funções de análise. Todas as três máquinas usadas para teste tiveram seu tráfego monitorado com a ferramenta.
Para monitorar o estado do servidor, foi usado uma ferramenta própria do servidor Apache\texttrademark ~\cite{apache}. A ferramenta
comumente chamada de \emph{server-status} é disponibilizada junto com a instalação do servidor Apache\texttrademark usado. O \emph{server-status}
assim que requisitado gera uma página html com informações sobre o estado do servidor, entre essas informações tem-se
o número de conexões do servidor e seus estados (ocupadas, ociosas, finalizadas e etc), o consumo de CPU, as últimas requisições feitas
ao servidor, lista de clientes, tempo do servidor e várias estatísticas. A ferramenta por ser bem completa e de fácil manuseio foi 
usada para monitorar os efeitos do ataque no servidor.

O método de testes usado foi bem simples e intuitivo. Para testar as ferramentas de ataque foi primeiramente preparada a rede, como já citado anteriormente. Com a rede montada, as três máquinas
tiveram a ferramenta Wireshark\texttrademark iniciada. Uma das ferramentas de ataque é, então, executada no computador atacante. Como a natureza do ataque
não é muito constante o seu efeito foi medido ao longo do tempo de execução, foi escolhido fazer medições a cada cinco minutos de ataque. Como
medições posteriores aos 15 minutos de ataque não mostraram muitas ocilações, foi escolhido fazer medições aos cinco, dez e quinze minutos.

A cada medição(aos 5, 10 e 15 minutos) foi usado a ferramenta \emph{server-status} no servidor para se obter informações sobre sua degradação, a 
ferramenta Wireshark\texttrademark também foi usada para saber o acrécimo de tempo que o cliente sofreu em suas requisições\footnote{
Foram feitas requisições de páginas simples e leves para esse teste, como o ataque funciona em servidores com TLS/SSL foram feitas 
requisições do mesmo caráter. Como o fluxo é cifrado, as medições de tempo foram feitas do início do \emph{handshake}
TLS/SSL até seu final, pois a criptografia não possibilita saber qual o conteúdo das requisições(pacotes cifrados).
Por consequência dessa medição, o tempo do atraso real sofrido pelo cliente é de fato maior que o registrado.}. Essas requisições
serviram para medir qual o nível de degradação de serviço que o cliente sofreu, foram feitas por volta de cinco requisições, o tempo médio
foi tomado e os valores foram comparados com valores do servidor em condições normais.

As medições foram feitas em todas as ferramentas de ataque citadas, uma a uma, usando-se diferentes números de instâncias(no caso da
API libevent que simula vários clientes em uma mesma máquina) e threads. As ferramentas foram testadas em separado, e a cada troca de ferramenta de ataque o servidor
foi reiniciado para garantir a limpeza de possíveis resquícios de testes anteriores.
